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SYSTEM AND METHOD FOR IMPLEMENTING A FLEXIBLE DATA-DRIVEN 

TARGET OBJECT MODEL 

BACKGROUND INFORMATION 

5 

An integrated development environment ("IDE") is typically used to develop 
software in a "target" computer system. The IDE includes one or more "host" 
installations which may be connected to the target system in order to load the developed 
software into the target system and monitor its execution. A number of altematives exist 

10 for connecting the target system to the host, but usually the connection is either an 
Ethernet or serial hnk. 

In a development system, the host is typically equipped with large amounts of 
RAM and disk space, backup media, printers, and other peripherals. In contrast, the 
target system typically has hmited resources (small amounts of RAM, no disk, no 

15 display, etc.), and perhaps some small amount of additional resources for testing and 

debugging. The target may include no more than a processor with on-chip RAM and a 
serial input/output channel. The target's processor may be of various kinds including the 
PowerPC® processor manufactured by IBM Corp. or the Pentium® II manufactured by 
Intel Corp. The target may also include an operating system, such as Vx Works® from 

20 Wind River Systems, Inc., which may be used to control the allocation and usage of the 

target's resources. 

The IDE may include a number of "tools" that allow a software developer to 
easily develop software for the target system and monitor the generation of the developed 
software on the target system. One such tool may be an "object browser" which can be 
25 conveniently used to monitor the state of the target system while developed appUcations 

are executing. The object browser can be used to display information about "objects" in 
the system, for example, information about objects of the operating system executing on 
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the target. These objects may include tasks, semaphores, message-queues, memory- 
partitions, watchdogs, etc. Each object also has attributes which are the properties of the 
object. For example, a semaphore (an object) may have as attributes its name, 
identification number, and state (e.g., whether the semaphore is taken). The attributes of 
5 an object may be static (i.e., determining the object attribute does not require access to 

the target system) or dynamic (i.e., determining the object attribute does require access to 
the target system). The static attributes of the object may include, among others, a string 
describing the type of object (e.g., for the semaphore, the string may be "Semaphore"), 
The dynamic attributes may include, among others, the name of the object, the object's 

10 identification number, and the state of the object. 

In a host-target development environment, in order for the host to gather 
information about the objects running on the target, the host generally has one or more 
files describing the target system's implementation of the object and this description file 
is specific to the implementation of the object by the operating system running on the 

15 target system. For example, the description files can list offsets to internal fields within 

each object's data structure, allowing the tools on the host to locate information 
concerning the object running on the target system. Information concerning the object is 
then retrieved from the target system using a standard communication protocol such as a 
Gopher program. The Gopher program describes a sequence of memory reads which 

20 results in a sequence of data to be returned to the calling host. 

This scheme just described for gathering information is unwieldy in practice and 
not easily scalable. It is expensive to extend and maintain because introducing a new 
object requires updating many architecture specific files. 

25 SUMMARY OF THE INVENTION 

A method and system for retrieving and presenting data from a target system, the 
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method includes retrieving object data from the target system for an object selected by a 
client, the retrieval performed by using one of the data retrieval programs corresponding 
to the target system. The method also includes providing the object data and a 
presentation format to the client, the object data and the presentation format are based 
5 upon one of the object description files corresponding to the object selected by the client. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig, 1 shows a block diagram illustrating a development environment according to a first 
exemplary embodiment of the present invention. 

Figs. 2a-b show a flowchart illustrating the steps involved in gathering object information 
according to the first exemplary embodiment of the present invention. 

Fig. 3 shows a user interface according to a second exemplary embodiment of the present 
invention. 

Figs. 4a-h show sample extensible Markup Language ("XML") code for implementing a 
semaphore object according to the second exemplary embodiment of the present 
invention. 

Fig. 5 shows a block diagram illustrating the development environment according to a 
third exemplary embodiment of the present invention. 

25 Figs. 6a-b show a flowchart illustrating the steps involved in gathering object information 

according to the third exemplary embodiment of the present invention. 
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Fig. 7 shows a block diagram of the development enviromnent according to a fourth 
embodiment of the present invention. 

Fig. 8 shows a flowchart illustrating the steps involved in gathering object information 
5 according to the fourth embodiment of the present invention. 

Figs. 9a-b show sample XML code for implementing a semaphore object according to the 
fourth embodiment of the present invention. 

10 DETAILED DESCRIPTION 

According to the present invention, a flexible object model may be implemented, 
for example, in the IDE employing host and target systems. The flexible object model 
allows information about objects running on the target to be gathered independently of a 
15 target's architecture (i.e., the operating system ruxming on the target and the processor 

architecture of the target). The flexible object model has the following benefits: 

(1) It supports an object framework usable by more than one development tool (i.e., can 
be used by any number of appUcations such as the browser, debugger, shell, etc.); 

(2) It presents an interface to a client (e.g., the object browser) that is independent of the 
20 target's operating system and processor architecture; 

(3) It allows browsing of public attributes of objects while hiding object implementation 
details; 

(4) It is self-descriptive regarding those objects that are supported for each given 
operating system, and this is user extensible by augmenting the existing (XML) 

25 database with descriptions of new objects; 

(5) It provides information regarding how object data may be most naturally presented 
and manipulated by the client; and 
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(6) It provides information about what actions on objects are permissible. 

In one exemplary embodiment of the present invention, extensible Markup 
Language (**XML") is used to describe the publicly accessible information of an object as 
well as the method by which that information can be accessed from the object and used in 
5 the IDE. XML is referred to as a "metalanguage", or a language for describing other 

languages. An XML file is made up of XML elements, each of which consists of a start 
tag (e.g., <title>), an end tag (e.g., </title>), and the information between the two tags 
(referred to as the content). Like Hypertext Markup Language ("HTML"), an XML 
document holds text annotated by tags. However, unlike HTML, XML allows an 

10 unlimited set of tags, each indicating not how something should look, but what something 
means. Rather than describing the order and fashion in which the data should be 
displayed, the tags in XML indicate what each item of data means. Detailed information 
on the XML standard is provided in; "Extensible Markup Language (XML) 1.0", W3C 
Recommendation lO-February-1998, REC-xml- 199802 10, http://www.w3.org/TR/REC- 

15 xml. 

XML allows the host to carry architecture-generic descriptions of objects, each 
object having an XML file. This architecture-generic description would define the object 
data to be returned from the target and also define its presentation to the client. XML is 
thus suited for implementing the exemplary embodiment because it allows for 
20 architecture-generic descriptions of how to access and use data pertaining to objects. 

The use of XML as the object description language would have the following 
benefits: 

(1) provides a machine readable object description; 

(2) it is an open standard which will allow the use of third party tools to browse, format, 
25 and manipulate the data contained in the XML database; 

(3) potential for users to use a tool to define their own objects; and 

(4) compilers to produce source-code, documentation, and browsing support. 
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Referring to the figures in which Hke numerals indicate hke elements, Fig. 1 is a 
block diagram illustrating an exemplary development environment 1 according to a first 
exemplary embodiment of the present invention. As shown, a host 10 is connected to a 
target 20 via, for example, a serial or Ethernet link. 
5 The host 10 may comprise a computing environment having various well-known 

components and systems (for example, a processor, a memory system, a display, and user 
input devices such as a keyboard and mouse.). The host 10 may include an operating 
system (e.g., Unix, Windows, Linux, etc.) which controls the execution of applications on 
the host 10. 

10 The target 20 may comprise a second computing environment which, for 

example, is intended to operate apart from the host 10. The processor of the target 20, for 
example, may be an Intel Pentium® II processor or an IBM PowerPC® processor. The 
target 20 may include fewer resources than the host 10, thus making it advantageous to 
perform software development on the host 10 prior to implementation in the target 20. 

15 The target 20 may include an operating system 150 which controls the execution of 

applications and other objects running on the target 20. The operating system 150, along 
with user applications running on the target 20, uses various kernel objects (''objects") 
such as semaphores and tasks. 

The host 10 includes a development system 15 to be used in developing software 

20 for the target 20. Included in the development system 15 is at least one chent 105, which 
may be one of a number of known development tools (e.g., the object browser, debugger, 
etc.). During operation, the cHent 105 may require information about objects running on 
the target 20. In order to monitor the operations of objects on the target 20, an 
application programming interface ("API") 1 10 is provided giving the client 105 access 

25 to an object interface C'OI") 115 and which allows the cUent 105 to access information 

(e.g., attributes) about the objects running on the target 20. The API 110 thus allows 
development tools such as the object browser, debugger, command line shell, etc. to 
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communicate with the 01 1 1 5. 

The 01 1 15 is a program that allows the client 105 to obtain information about 
objects running on the target 20 independently of the target's architecture (which is 
described below) or its operating system. The 01 115 also includes an XML interpreter 

5 which is used to read XML files and provide access to their content and structure. 

The development system 15 also includes a target interface ("TI") 120 which is 
used by the 01 1 1 5 to access information about the objects running on the target 20. The 
TI 120 includes the Gopher standard protocol which is used to gather information about 
an object running on the target 20. 

10 The development system 15 further includes an object database containing 

descriptions of objects for each known operating system and also data retrieval programs 
for various target processor architectures. In the first exemplary embodiment, the object 
database is an XML object database 130 and the object descriptions for each known 
operating system are implemented using XML. Also, in the first exemplary embodiment, 

15 Gopher programs, corresponding to recognized target processor architectures, are the data 
retrieval programs. However, in other embodiments, the object descriptions may be 
implemented using other languages and other programs may be used to retrieve data from 
the target 20. The XML object database 130 may be accessed by the 01 115 in order to 
process requests by the client 105 for information about an object running on the target 

20 20. 

Figs. 2a-b (hereinafter, collectively referred to as 'Tig. 2") show a flowchart 
illustrating the steps involved in gathering information about the objects running on the 
target 20 using the first exemplary embodiment of the present invention. In step 203, the 
chent 105 is launched by, for example, a user. In step 206, the cUent 105 instantiates the 
25 01 1 15 in order to get object information from the target 20. The 01 1 15 needs to be 

initiaHzed. In step 209, the 01 1 15 queries the target 20 via the TI 120 for information 
regarding the processor type and the operating system 150 of the target 20 and retrieves 
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this information from the target 20. In step 215, the 01 1 15 loads the XML object 
description files for the specified target operating system from the XML object database 
130. After the XML object description files are loaded and successfully validated against 
a Document Type Definition ("DTD") file, the 01 1 15 is now initialized, 

5 In step 221, the client 105 "enumerates" all the objects supported by the 01 115. 

Enumerating the objects means to determine all the static attributes of the known objects, 
i.e., those attributes which do not require access to the target 20. The client 105 is 
provided enumeration information (i.e., information about the static attributes of the 
object) by the 01 1 15. The 01 1 15 obtains the enumeration information solely by using 

10 the XML object descriptions in the XML object database 130: there is one XML object 
description per object supported. No reference is made to the target 20 via the TI 120 for 
enumeration of the supported objects. The attributes of each object are defined in the 
XML object database 130 and may include, among others, the name of the object, the 
standard icon, the state, label, whether the object is displayable, how data displayed, etc. 

15 In step 227, the client 105 requests further details about an object selected by the 

user. In step 230, the cUent 105 sends a reference to the object selected to the 01 1 15 via 
the API 110. In step 233, the 01 1 15 accesses the XML object database 130 to retrieve 
the XML object description corresponding to the selected object. The 01 1 15 also 
retrieves from the XML object database 130 the Gopher program corresponding to the 

20 processor of the target 20. A Gopher program may exist for each of the many possible 
target processor architectures if such a program is required - an advantage of this 
embodiment of the present invention is that a Gopher program can be shared by different 
target processor architectures if they use the same memory layout for software objects. 
In step 239, the 01 1 15 accesses the target 20 using a data retrieval method to 

25 collect data from the target 20. In one embodiment, the data retrieval method is passing 

the Gopher program from the 01 1 1 5 through the TI 120 to the target 20 in order for the 
01 1 15 to gather data about the selected object. The returned data is referred to as a 
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"Gopher tape." In step 242, the 01 1 15 decodes the data returned from the target 20 
based on the XML object description retrieved from the XML object database 130. In 
step 245, the 01 1 15 sends the decoded data to the chent 105 along with a presentation 
format. The presentation format is also based on the XML object description and 

5 instructs the client 105 on how to display the decoded data. The decoded data and the 

presentation format allow the chent 105 to be data driven. The decoded data for the 
selected object is returned to the client 105 as a set of object attributes. In step 248, the 
chent 105 uses the set of object attributes which was returned as a result of the original 
request. Such use of the object attributes can be, for example, in the case of the object 

10 browser, to display the object's attributes in a format suitable for a graphical user 

interface ("GUI"). 

The previous embodiment shows how the 01 1 15 can be used to retrieve 
information about objects running on the target. In a second exemplary embodiment 
according to the present invention, the 01 1 15 can be used by a specific development tool 

15 - an object browser - to display information about objects running on a specific target. In 

this example, the processor of the target 20 is the PowerPC® processor, and the operating 
system 1 50 of the target 20 is Vx Works®. In other alternative embodiments, the 01 1 15 
may be used by other development tools such as a debugger (e.g., the debugger would 
need to enumerate tasks in order to attach to one of them), and a command line shell 

20 (e.g., the shell may provide system information such as a snapshot of the tasks running on 
the target). 

The following example illustrates the use of the exemplary 01 1 15 and the XML 
object database 130 by the object browser to obtain information (i.e., attributes) about 
objects running on the target. Referring again to Fig. 2 but now for the case where the 
25 client 105 is specifically the object browser, in step 203, the object browser is launched 

by, for example, the user. In step 206, the object browser instantiates the 01 115 in order 
to get object information from the target 20. In step 209, the 01 1 15 queries the target 20 
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via the TI 120 for information regarding the processor type and the operating system 150 
of the target 20 and retrieves this information from the target 20. 

In step 215, the Oil 15 loads the XML object descriptions for Vx Works® from 
the XML object database 130. In step 221, the object browser enumerates all object 

5 types supported by the 01 1 15 using the XML object descriptions obtained from the 

XML object database 130. In step 227, the object browser requests further details on a 
particular object selected by the user of the object browser. In step 230, the object 
browser sends the object selected to the 01 1 15 via the API 110. 

In step 233, the 01 1 15, based on the object selected, retrieves the corresponding 

10 XML object description from the XML object database 130. The 01 1 15 also retrieves 

from the XML object database 130 the Gopher program corresponding to the PowerPC® 
processor in order to retrieve the attributes of the selected object running on the target 20. 
In step 239, the 01 1 15 accesses the target 20 to retrieve the attributes of the selected 
object running on the target 20 using the Gopher program by sending the Gopher 

15 program through the TI 120 to the target 20. 

In step 242, the 01 1 15 decodes the data returned from the target 20 based on the 
XML object description retrieved from the XML object database 130. In step 245, the 01 
1 15 sends the decoded data (i.e., object attributes) to the object browser along with the 
presentation format. In step 248, the object browser displays the object attributes in the 

20 format as specified by the presentation format. 

Fig. 3 shows a user interface of the object browser according to the second 
exemplary embodiment of the present invention. In Fig. 3, all of the objects types 
supported are shown. The object types supported here are: (1) protection domains, (2) 
memory partitions, (3) tasks, (4) semaphores, (5) message queues, (6) watchdogs, (7) 

25 page managers, (8) page pools, (9) virtual memory contexts, (10) file descriptors, and 
(1 1) modules. In Fig. 3, a task browser is selected, allowing the user to see detailed 
information about a particular task. The task list shown (tMgrTask, tExcTask, etc.) in 
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Fig. 3 is retrieved from the target 20, The user can expose frirther levels of detail by 
clicking the "plus sign" icon. In Fig, 3, specific object attributes of tWdbTask are shown 
such as its ID, Name, Owner, Status, etc. 

Figs. 4a-h (hereinafter, collectively referred to as "Fig. 4") show sample XML 
5 code for implementing a semaphore object according to the second exemplary 

embodiment. The first Une of Fig. 4 is an XML declaration which specifies the version 
of XML being used (here, version "1.0" is used). The first line also contains an encoding 
declaration (here, characters are encoded using UTF-8). The second line references the 
external DTD file. This file essentially defines the rules of the document, such as which 

10 elements are present and the structural relationships between the elements. In line two, 

the "objTypes.dtd" is defined as the DTD. With XML, DTDs are optional 

The third and fourth lines of Fig. 4 define the specifics of the object type. For 
example, the object is defined as a semaphore (objTypeName - "sem") and given a 
unique object number (objTypeNumber = "1"). 

15 The "objTypeAttributes" in Fig. 4 contain descriptions of those attributes which 

are static, i.e., those attributes which do not require target access. The "obj Attributes" 
contain descriptions of those attributes which do require target access. The "obj Gopher" 
contains the Gopher programs used by the 01 1 15 for each target architecture along with 
a logical identifier to be attached to the retumed value. This identifier is referenced in the 

20 "obj Attribute" to decode the retumed data. 

Fig. 5 is a block diagram illustrating a third exemplary embodiment according to 
the present invention where a user-defined XML object database 135 is added to the 
development system 15. The user-defined XML object database 135 may contain user- 
defined object descriptions. In one embodiment, the user-defined object descriptions are 

25 in XML in order for the object descriptions to be architecture-generic. The user-defined 

XML object database 135 provides for the extension of known objects by adding to the 
database a user-defined XML object description which describes the new object. The 
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user-defined XML object database 135 allows the user to add custom objects and thus 

expand the number of objects supported by the 01 1 15. 

Figs. 6a-b (hereinafter, collectively referred to as 'Tig. 6") show a flowchart 

illustrating the steps involved in gathering information about the objects running on the 
5 target 20 using the third exemplary embodiment of the present invention. In this 

exemplary embodiment, step 218 is added to the steps described earlier in Fig. 2 for 

gathering information about an object running on the target 20. 

Referring to Fig. 6, in step 218, the 01 1 15 loads the user-defined XML object 

descriptions (the plug-ins) from the user-defined XML object database 135 for the 
10 specified target operating system. The plug-ins allow the user to add custom objects. 

The plug-ins also allow the 01 1 15 to support user defined custom objects. The plug-ins 

expand the number of objects that are supported by the 01 1 15. After the plug-ins are 

loaded in step 218, the 01 1 15 is now initialized. 

In a fourth embodiment of the present invention, data extraction routines are used 
15 rather than the Gopher program to retrieve object data from the target 20. Fig. 7 is a 

block diagram illustrating the development environment 1 according to the fourth 

embodiment of the present invention. 

Included in a data extraction development system 25 is an object description 

module 155 which contains descriptions of each of the objects running on the target 20. 
20 In order for the object descriptions to be architecture-generic, they are implemented using 

XML, The object description module 155 contains XML code for describing each of the 

object's public attributes. The object description module 155 also contains data 

extraction routines; each object description specifies a data extraction routine for that 

object. Different data extraction routines may exist for each target processor architecture 
25 supported by the data extraction development system 25 and the data extraction routines 

may be pre-compiled using the appropriate compiler. 

The data extraction routine is downloaded to the target 20 via the TI 120 in order 
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to assemble data about the selected object on the target 20 in the format described in the 
XML object description found in the object description module 155. In an alternative 
embodiment, the data extraction routine already resides on target 120 and therefore does 
not need to be downloaded. The data extraction routine assembles the data about the 

5 selected object on the target 20 into a data packet and places it in a target buffer. 

Figure 8 is a flowchart illustrating the steps involved in gathering object 
information in the fourth embodiment of the present invention. In step 505, the client 
105 is launched by, for example, a user. In step 510, the 01 1 15 queries the target 20 via 
the TI 120 for information regarding the processor type and the operating system 150 of 

10 the target 20. In step 512, the 01 1 15 loads the XML files for the specified target 

operating system from the object description module 155. In step 514, the chent 105 
"enumerates" (determines) all the object types supported by the 01 1 15. 

In step 515, the client 105 selects an object for which to obtain information and 
this selection is sent to the 01 1 15 via the API 110. In the case of the object browser, the 

15 object whose public attributes are to be displayed is selected by a user. In step 520, the 

object description for the selected object is fetched from the object description module 
155. In step 525, the data extraction routine corresponding to the processor architecture 
of the target 20 is fetched from the object description module 155. 

In step 535, the compiled data extraction routine is sent to the target 20 via the TI 

20 120. In step 540, the data extraction routine assembles the requested data for the selected 

object and places this data into a data packet and puts this data packet into a target buffer. 
In step 550, the 01 1 15 uses the object description, found earlier in the object description 
module 155, in order to interpret the retrieved data. The 01 1 15 formats the requested 
data by matching it with the object description found in the object description module 

25 1 55. In step 555, the 01 1 15 sends the decoded data to the client 105, In the case that the 

client 105 is the object browser, the decoded data (the object information) can be 
displayed to the user. 
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Figs, 9a-b (hereinafter, collectively referred to as "Fig. 9") show a sample hsting 
of XML code used to implement a semaphore object according to the fourth embodiment 
of the present invention. The first line of Fig. 9 is an XML declaration which specifies 
the version of XML being used (here, version "1.0" is being used). The first line also 

5 contains an encoding declaration (here, characters are encoded using UTF-8). The 

second line specifies the name of the object; in Fig. 9, the object is named 
"binarySemaphore". A <requestBegin> element defines the routine (i.e., the data 
extraction routine) needed to request object data to be collected. A <requestEnd> 
element defines the routine needed to complete the object data request. 

10 A <data> element defines the data assembled for use by the object browser. The 

<data> element includes the definition of the data items which will be assembled by the 
target 20 and downloaded to the host 10 in a data packet. The host 10 uses <dataltem> 
definitions in the <data> element to decode this data packet. For each <dataltem>, 
information is provided to allow the host 10 to extract the data from the data packet and 

15 to know how to display it in the object browser. A "type" attribute specifies the number 
of bytes in the data item and how it should be interpreted. A "idref ' attribute is an 
internal name for the dataltem. A "text" attribute is the label to be used in the object 
browser for the dataltem. A "format" attribute is a C-style format stating how the data 
should be displayed by the client. A "display" attribute indicates whether the dataltem is 

20 displayed; if display is set to "always" then the dataltem is always displayed, if display is 
set to "optional" then the user can elect to display the dataltem, and if display is set to 
"never" then the dataltem is never displayed. 

In the preceding specification, the invention has been described with reference to 
specific exemplary embodiments thereof It will, however, be evident that various 

25 modifications and changes may be made thereunto without departing from the broader 

spirit and scope of the invention as set forth in the claims that follow. The specification 
and drawings are accordingly to be regarded in an illustrative rather than restrictive sense. 
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WHAT IS CLAIMED IS: 

1 . A method for retrieving and presenting data from a target system, comprising: 
receiving target system information from the target system; 

retrieving a set of object description files corresponding to the target system 
information; 

sending to a client a set of objects supported based on the set of object description 
files retrieved; 

receiving a selected object from the cUent; 

selecting one of the set of object description files corresponding to the selected 

object; 

retrieving one of a set of data retrieval programs corresponding to the target 
system information; 

retrieving object data about the selected object using the retrieved one of the set of 
data retrieval programs; 

decoding the object data about the user selected object using the selected one of 
the set of object description files corresponding to the selected object to form decoded 
object data; and 

sending the decoded object data and a presentation format to the client allowing 
the client to be data driven. 

2. The method of claim 1 wherein the target system information includes a processor 
type of the target system and an operating system type of the target system. 

3. The method of claim 2 wherein the set of object description files is a set of XML 
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object description files and the set of data retrieval programs is a set of Gopher programs. 

4. The method of claim 3 wherein retrieving the set of object description files 
corresponding to the target system information includes retrieving the set of XML object 
description files corresponding to the operating system type of the target system. 

5. The method of claim 4 wherein retrieving the set of object description files 
corresponding to the target system information includes retrieving a set of user-defined 
XML object description files corresponding to the operating system type of the target 
system. 

6. The method of claim 1 wherein the selected object is received fi-om the client 
using an application programming interface. 

7. The method of claim 5 wherein retrieving one of the set of data retrieval programs 
corresponding to the target system information includes retrieving one of the set of 
Gopher programs corresponding to the processor type of the target system, 

8. The method of claim 7 wherein retrieving the object data about the selected object 
includes passing the retrieved one of the set of Gopher programs through a target 
interface to retrieve the object data for the selected object from the target system. 

9. The method of claim 1 wherein the client is an object browser. 
Express Mail No: EL502647533US 
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1 0. The method of claim 3 wherein the set of XML object description files is stored in 
an XML object database and the set of Gopher programs is stored in the XML object 
database. 

1 1 . The method of claim 2 wherein the set of object description files is a set of XML 
object description files and the set of data retrieval programs is a set of data extraction 
routines. 

12. The method of claim 1 1 wherein accessing the object database to retrieve one of a 
set of data retrieval programs corresponding to the target system information includes 
accessing the object description module to retrieve one of the set of data extraction 
routines corresponding to the processor type of the target system. 

1 3 . The method of claim 1 2 wherein retrieving the obj ect data about the selected 
object includes passing the retrieved one of the set of data extraction routines through a 
target interface to retrieve the object data for the selected object fi-om the target system. 

14. The method of claim 13 wherein the set of XML object description files is stored 
in an object description module and the set of data retrieval programs is stored in the 
object description module. 
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15. A development system, comprising : 
a client; 

an object database including a set of object description files and a set of data 
retrieval programs, the set of object description files including at least one object 
description file corresponding to an object selected by the chent, the set of data retrieval 
programs including at least one data retrieval program corresponding to the target system; 

an object interface coupled to the client and the object database to retrieve object 
data from an object in the target system using the at least one data retrieval program 
corresponding to the target system, and providing the object data to the client based on 
the at least one object description file corresponding to the object selected by the client; 
and 

a target interface coupled to the object interface to enable connection of the object 
interface to the target system. 

1 6. The development system of claim 1 5 wherein the object interface obtains target 
system information from the target system, the target system information including a 
processor type of the target system and an operating system type of the target system. 

17. The development system of claim 1 5 wherein the coupUng between the client and 
the object interface includes an application programming interface. 

1 8 . The development system of claim 1 5 wherein the cHent is an obj ect browser. 
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19. The development system of claim 1 5 wherein the object database is aa XML 
object database and the set of object description files are a set of XML object description 
files and the set of data retrieval programs are a set of Gopher programs. 

20. The development system of claim 19 further comprising a user-defmed XML 
object database coupled to the object interface and including a set of user-defmed XML 
object description files corresponding to a set of user-defined objects. 

21 . The development system of claim 20 wherein the object interface retrieves the set 
of XML object description files corresponding to the operating system type of the target 
system and the set of user-defined XML object description files corresponding to the 
operating system type of the target system. 

22. The development system of claim 21 wherein the cHent enimierates a set of 
objects supported using the set of XML object description files and the set of user- 
defmed XML object description files. 

23. The development system of claim 22 wherein the object interface receives the 
object selected by the chent. 

24. The development system of claim 23 wherein the object interface retrieves a 
particular one of the set of XML object description files corresponding to the object 
selected by the chent and retrieves a particular one of the set of Gopher programs 
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corresponding to the processor type of the target system. 

25. The development system of claim 24 wherein the object interface retrieves the 
object data from the object in the target system by sending the retrieved one of the set of 
Gopher programs through the target interface into the target system. 

26. The development system of claim 25 wherein the object data is decoded using the 
retrieved one of the set of XML object description files to form decoded object data. 

27. The development system of claim 26 wherein the decoded object data and a 
presentation format is sent to the cUent allowing the client to be data driven. 

28. The development system of claim 16 wherein the object database is an object 
description module and the set of object description files in the object database are a set 
of XML object description files and the set of data retrieval programs in the object 
database are a set of data extraction routines. 

29. The development system of claim 28 wherein the object interface retrieves a 
particular one of the set of data extraction routines corresponding to the processor type of 
the target system. 

30. The development system of claim 29 wherein the object interface retrieves the 
object data from the object in the target system by passing the retrieved one of the set of 
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data extraction routines through the target interface into the target system. 

31. A method for retrieving and presenting data from a target system, comprising: 
retrieving object data from the target system for an object selected by a chent, the 

retrieval performed by using one of the set of data retrieval programs corresponding to 
the target system; and 

providing the object data and a presentation format to the client, the object data 
and the presentation format based upon one of a set of object description files 
corresponding to the object selected by the cUent. 

32. The method of claim 3 1 wherein retrieving the object data includes receiving 
target system information from the target system. 

33. The method of claim 32 wherein retrieving the object data includes retrieving a 
set of object description files corresponding to the target system information. 

34. The method of claim 33 wherein retrieving the object data includes sending to the 
client a set of objects supported, the set of objects supported based on the set of object 
description files retrieved. 
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35. A device comprising: 
a medium; and 

a set of instractions recorded on the medium; 

wherein the set of instructions, when executed by a processor, cause the processor 
to: 

receive target system information from the target system; 

retrieve a set of object description files corresponding to the target system 
information; 

send to a cUent a set of objects supported based on the set of object description 
files retrieved; 

receive a selected object from the client; 

select one of the set of object description files corresponding to the selected 

object; 

retrieve one of a set of data retrieval programs corresponding to the target system 
information; 

retrieve object data about the selected object using the retrieved one of the set of 
data retrieval programs; 

decode the object data about the user selected object using the selected one of the 
set of object description files corresponding to the selected object to form decoded object 
data; and 

send the decoded object data and a presentation format to the client allowing the 
client to be data driven. 
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ABSTRACT 

A method and system are disclosed for a flexible data-driven target object model 
which allows a client to gather and present information about objects on a target system 
independently of the target's operating system and processor architecture. The object 
5 descriptions are implemented using XML in order to provide architecture-generic 

descriptions of objects. The architecture-generic descriptions define the object data to be 
returned from the target and also defines its presentation to the user. 

SJOl 15135 V 5 
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<?xml version-" 1.0" encoding="UTF-8"?> 
<!DOCTYPE objType SYSTEM "objTypes.dtd"> 

<objType objTypeNumber="l" objTypeNaine="sem" objTypeHandler="tom" 
syinbolTableName=" semClassId"> 
<objTypeAttributes> 

<objTypeAttribute key="objTypeVisiblityLevel"> 
<value type="Integer"> 

<literal>l</literal> 

</value> 
<formatStr> 

<literal>%d</literal> 
</formatStr> 
</ obj Typ e Attribute> 

<objTypeAttribute key="objTypeStringl "> 

<valueStr> 

<literal>Semaphore</literal> 

</valueStr> 
</objTypeAttribute> 

<objTypeAttribute key-"objTypeString2"> 

<valueStr> 

<literal>Semaphores</literal> 

</valueStr> 
</objTypeAttribute> 

<objTypeAttribute key="objTypeIconLarge"> 

<valueStr> 

<literal>semL,ico</literal> 

</valueStr> 
</objTypeAttribute> 

<objTypeAttribute key="objTypeIcoiiSmaH"> 
<valueStr> 

<literai>sem. gif</literal> 
</valueStr> 
</objTypeAttribute> 
</ obj Type Attributes> 
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<objAttributes> 

<objAttribute key="objId"> 
<label> 

<literal>ID</literal> 

</label> 
<value> 

<substitute fieldName="objId7> 

</value> 
<fonnatStr> 

<literal>%08x</literal> 
</formatStr> 
<detailLevel> 

<literal>l</literal> 
</detailLevel> 
</objAttribute> 

<objAttribute key="objNaine"> 
<label> 

<literal>Name</literal> 

</label> 
<value> 

<substitute fieldName="objName"/> 

</value> 
<fonnatStr> 

<literal>%s</literal> 
</fonnatStr> 
<detailLevel> 

<literal>l</literal> 
</detailLevel> 
</objAttribute> 

<objAttribute key="obj Owner "> 
<label> 

<literal>Owner</literal> 

</label> 
<value> 

<substitute fieldName="obj Owner "/> 

</value> 
<fonnatStr> 

<literal>0x%08x</literal> 
</formatStr> 
<detailLevel> 

<literal>l</literal> 
</detailLevel> 
</objAttribute> 
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<objAttribute key="objHasChildren"> 
<value> 

<switchfieldName-"objChildListPtr"> 
<case caseValue-"0"> 

<literal>false</literal> 

</case> 

<case caseValue="*"> 

<literal>true</literal> 

</case> 
</switch> 

</value> 

<formatStr> 

<literal>%s</literal> 

</formatStr> 
</objAttribute> 
<objAttribute key="objType'*> 

<label> 

<literal>Type</literal> 

</label> 
<value> 

<substitute fieldNaine="seinType'V> 

</value> 
<fonnatStr> 

<literal>Ox%x</literal> 
</formatStr> 
<valueStr> 

<s witch fieldName="semType"> 
<case caseValue="0"> 

<liter al>B inary</literal> 

</case> 

<case caseValue="r'> 

<literal>Mutex</Iiteral> 

</case> 

<case caseValue="2"> 

<literal>Counting</literal> 

</case> 

<case caseVaiue="*"> 

<literal>UNKNOWN</literal> 

</case> 
</switch> 
</valueStr> 
<detailLevel> 

<literal>l</literal> 
</detailLevel> 
</objAttribute> 



Fig. 4d 



<objAttribute key="obj State "> 

<! "There are two label entries here. The first will be overridden by the second, 
if the second does not return a null value when processed, i.e. if the fieldMap contains an entry for the 
"semType" fieldName, the second label will override the first when processed. In the case of a 
getDatabaseAttributesO call, the second will return a null since "semType" will not be in the field map, and 
the value contained in the first will persist.--> 

<label> 

<literal>State/Count/Owner</literal> 

</label> 
<label> 

<switch fieldName="semType"> 
<case caseValue="0"> 

<! -Binary Semaphore--> 
<literal>State</literal> 

</case> 

<case caseValue="l"> 

<1-Mutex Semaphore-> 
<literal>Owner</literal> 

</case> 

<case caseValue="2"> 

<! --Counting Semaphore-> 
<literal>Count</literal> 

</case> 

<case caseValue="*"> 

<literal>Owner</literal> 

</case> 
</switch> 

</label> 
<value> 

<substitute fieldName="semState"/> 

</value> 
<formatStr> 

<switch fieldName="semType"> 
<case caseValue=="2"> 

<!--Counting Semaphore - display as decimal-> 
<literal>%d</literal> 

</case> 

<case caseValue="*"> 

<!-Any other sort of semaphore - display as hex--> 
<literal>Ox%x</literal> 

</case> 
</switch> 
</formatStr> 
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<valueStr> 

<! -Override the valueStr, even though the value and formatStr has 
been specified. This allows decoding of the Semaphore static into plain text. The only option is for a 
Counting, or unknown Semaphore, where no CaseValue is specified. This allows the XML code to fall 
through the Switch statement without finding a match. In this case, no value will be inserted into the 
valueStr from here, leaving the XML code to compose one from the contents of the value combined with 
the formatStr.--> 

<switch fieldName="semType"> 
<case caseValue="0"> 

<! --Binary Semaphore~> 
<s witch fieldName="semState"> 
<case caseValue="0"> 

<literal>FULL</literal> 

</case> 

<case caseValue="*"> 

<literal>EMPTY</literal> 

</case> 
</switch> 

</case> 

<case caseValue==" 1 "> 

<!~Mutex Semaphore--> 
<switch fieldName="semState"> 
<case caseValue="0*'> 

<literal>Unowned</literal> 

</case> 
</switch> 

</case> 

<!-For caseValue = 2 (Counting semaphore) or for any 
other value, let this fall through without filling in a value. In this case, a valueStr will be composed 
automatically from the value and formatStr entries~> 

</switch> 
</valueStr> 
<detailLevel> 

<literal>l</literal> 
</detailLevel> 
</objAttribute> 

<objAttribute key="objOptions"> 
<label> 

<literai>Options</literal> 

</label> 
<value> 

<substitute fieldName="semOptions7> 

</value> 
<formatStr> 

<literal>0x%08x</literal> 
</formatStr> 
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<valueStr> 

<typedef> 

<switch fieldName="semOptions" fieldMask-" 0x0003 "> 
<case caseValue="0"> 

<literai>SEM_Q_FIFO</literal> 

</case> 

<case caseValue-' 1 "> 

<literal>SEM_Q_PRIORITY</literal> 

</case> 

<case caseValue=="*"> 

<literal>SEM_Q_UNKNOWN</literal> 

</case> 
</switch> 

<bitfield fieldName="semOptions" 

fieldMask-"OxFFFFFFFC"> 
<bitmask="0x0004"> 

<literal>SEM_DELETE_SAFE</literal> 

</bit> 

<bitmask="0x0008"> 



<literal>SEM_rNVERSION_SAFE</literal> 

</bit> 

<bit mask-"*"> 

<literal>SEM_UNKNOWN</literal> 

</bit> 
</bitfield> 
</typedef> 
</valueStr> 
<detailLevel> 

<literal>l</literal> 
</detailLevei> 
</objAttribute> 

<objAttribute key="objIconSmair'> 
<valueStr> 

<switch fieldName="semState"> 
<case caseValue="0"> 

<literal>sein. gif</literal> 

</case> 

<case caseValue='**"> 

<literal>semempty.gif</literal> 

</case> 
</switch> 
</valueStr> 
</objAttribute> 
</objAttributes> 
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<objGopher> 

<switch fieldName^'*cpu"> 

<case caseValue="*"> 
<program> 

<! --Default Get object info for sem - taken from PPC860"> 
<![CDATA[! <+0x30*<+0x30@» 
<+0x28*$><+0x20*!><+0x8@>%nameLookap%<+0x34@b><+0x35@b><+0x48@>]]> 

</program> 

<tape> 

<field fieldName="objId7> 
<field fieldName-"objTypeNumber7> 
<field fieldName="objName7> 
<field fieldName="objOwner7> 
<fieldfieldName="objChildListPtr'7> 
<field fieldName="semType"/> 
<field fieidName^"semOptions'V> 
<field fieldName="semState7> 

</tape> 

</case> 
</switch> 
</objGopher> 
<enuinByType> 

<switch fieldName="cpu"> 

<case caseVaiue="*"> 
<program> 

<![CDATA[*+0x38** -0x18! <+0x30*<+0x30@» 
<+0x28*$><+0x20*!><+0x8@> <+0x34@b><+0x35@b><+0x48@>+0xl8@]]> 

</program> 
<tape> 

<field fieldName="objId7> 
<field fieldName="objTypeNumber7> 
<field fieldName="objName7> 
<field fieldName="objOwner7> 
<field fieldName="objChildListPtr7> 
<field fieldName="semType"/> 
<field fieldName="semOptions7> 
<field fieldName="semState7> 
<field fieldName="objSiblingPtr7> 

</tape> 
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<prograin> 

<![CDATA[%objSiblingPtr% -0x18! <+0x30*<+0x30@» 
<+0x28*$><+0x20*!><+0x8@><+0x34@b><+0x35@b><+0x48@>+0xl8@]]> 

</program> 
<tape> 

<field fieldName="objId7> 
<field fieldName-"objTypeNumber'7> 
<field fieldName="objName7> 
<field fieldName-"objOwner7> 
<fieldfieldName="objChildListPtr'7> 
<field fieldName-"semType7> 
<field fieldName="seinOptions7> 
<field fieldName="semState'7> 
<field fieldName="objSiblingPtr7> 

</tape> 

</case> 
</switch> 
" Z <l enumByType> 

.^Jrl </objType> 
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<?xml version="LO" encoding"utf-8"?> 
<object name="binarySemaphore" 

icon="k:\wpwr\host\resource\bitmaps\WindView\events\semBCreate.bm 
<helpText> 

<synopsis> 

This is a short description of the object. 
</synopsis> 

<description> 

This is a much longer description of the object. 

This description can contain anything the user desires. 
<description> 

</helpText> 

<pubHcDataGet> 

<helpText> 

<synopsis>Get all public data members</ synopsis> 
<description> A full description of the routine</description> 
</help Text> 

<requestBegin> 

<call name="semRequestBegin"/> 

<retum type="UINT8'^'V> 

<parm type="SEMJD"name-"semId'7> 

</requestBegin> 

<requestEnd> 

<callname="semRequestEnd'V> 
<retum type= "STATUS"/> 
<parm type="UINT8 name-"pBuff V> 
</requestEnd> 
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<data> 

<dataltem type="UINT"idref="pkLength"display-"never"/> 
<dataItemtype="UINT"idref="semId" 

text="Handle"format="0x08x"display="always" 

position="17> 

<dataItemtype="UINT"idref="semClassId"display="never"/> 
<dataltem type="string" idref- 'name" 

text="Name" format="%s" display="always" 

position="0"/> 
<dataltem type="string" idref="owner" 

text="Owner" format="%s" display="always" 

position="27> 
<dataltemtype="int"diref="value" 

text="State"format="translate"display="always" 

position="3" 

<translate key ="0" value="Empty" foimat="%s"/> 
<translate key="r' value="Taken" fonnat="%s"/> 
<translate key="*"value-"Unknown" fonnat="%s"/> 
</dataItem> 

</data> 

</pubicDataGet> 



</object> 
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PRIOR FOREIGN APPLICATION(S) 

I hereby claim foreign priority benefits under 35 USC §11 9(a-d) or §365(b) of any foreign appiication(s) for patent or inventor's certificate, or 
§365(a) of any PCT International application which designated at least one country other than the United States, listed below and have also 
identified below any foreign application(s) for patent or inventor's certificate, or PCT International application having a filing date before that of 
the applicafion on which priority is claimed: 



Application Number 


Country 


Filing Date (day/month/year) 


Priority Not Claimed 











PROVISIONAL APPLICATION{S) 



I hereby claim the benefit under 35 USC §119(e) of any United States provisional applicatlon(s) listed below: 



Application Number 




Filing Date 





PRIOR UNITED STATES APPLiCATION{S) 



I hereby claim the benefit under 35 USC §120 of any United States application(s), or §365(c) of any PCT international application designating 
the United States, listed below and, insofar as the subject matter of each of the claims of this application is not disclosed in the prior United 
States or PCT International application in the manner provided by the first paragraph of 35 USC §112,1 acknowledge the duty to disclose 
information which is material to patentability as defined in 37 CFR §1 .56 which became available between the filing date of the pnor 
application and the national or PCT International filing date of this application: 



Application Number 


Filing Date 


Status (patented, pending, abandoned) 









POWER OF ATTORNEY 



I hereby appoint the following attorney(s) and/or agent(s) to prosecute this application and to transact all business in the Patent and 
Trademark Office connected therewith. 



Paul H. Heller (Reg. No. 21,074), Felix L. D'Arienzo, Jr. (Reg. No. 27,631), Joseph R. Palmieri (Reg. No. 40,760), and Thomas George {Reg. 
No. P-45,740) of KENYON & KENYON, 333 W. San Carlos St., Suite 600, San Jose, CA 951 10, telephone 408-975-7500. 
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DECLARATION AND POWER OF ATTORNEY FOR PATENT APPLICATION (Cont) 


Direct telephone calls to: 

Joseph R. Palmieri 
(408) 975-7500 


Send correspondence to: 

KENYON & KENYON 

333 W. San Carlos, Street, Suite 600 

San Jose, CA 95110-2711 


1 hereby declare that ail statements made herein of my own l<nowIedge are true and ail statements made on information and belief are 
believed to be true; and further that these statements were made with the knowledge that willful false statements and the like so made are 
punishable by fine or imprisonment, or both, under §1001 of Title 18 of the United States Code and that such willful statements may 
jeopardize the validity of the application or any patent issuing thereon. 


Full name of first or sole 
inventor 


Last Name 
STREET 


First Name 
NIGEL 


Middle Name 


Residence: 

36 RUSSLEY CLOSE 


City 

SWINDON 


State or Country 
ENGLAND 


Country of Citizenship 
GREAT BRITAIN (GB-3) 


Post Office Address: 


Street 

36 RUSSLEY CLOSE 


City 

SWINDON 


State or Country & Zip Code 
ENGLAND, SN5 SAG 


Signature 


Date 


Fuli name of second inventor 


Last Name 
CHERRINGTON 


First Name 
CHRISTOPHER 


Middle Name 


Residence: 

32 CRANE FURLONG 


City 

SWINDON 


State or Country 
ENGLAND 


Country of Citizenship 
GREAT BRITAIN {GB-3) 


Post Office Address: 


Street 

32 CRANE FURLONG 


City 

SWINDON 


State or Country & Zip Code 
ENGLAND, SN6 TJX 


Signature 


Date 


Fuli name of third inventor 


Last Name 
ROBINSON 


First Name 
TIM 


Middle Name 


Residence: 

13 NORTH IVIEADOW ROAD 


City 

CRICKLADE 


State or Country 
ENGLAND 


Country of Citizenship 
GREAT BRITAIN (GB-3) 


Post Office Address: 


Street 

13 NORTH MEADOW ROAD 


City 

CRICKLADE 


State or Country & Zip Code 
ENGLAND, SN6 6LT 


Signature 


Date 


Fulf name of fourth inventor 


Last Name 
IWcDERIWOTT 


First Name 
ANDREW 


Middle Name 


Residence: 

3 GILMAN CLOSE 


City 

SWINDON 


State or Country 
ENGLAND 


Country of Citizenship 
GREAT BRITAIN (GB-3) 


Post Office Address 


Street 

3 GILMAN CLOSE 


City 

SWINDON 


State or Country & Zip Code 
ENGLAND, SN2 3GJ 


Signature 


Date 
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